Data processing is one of the most important functions of a computing system. The results of data processing are often arranged in a report, which may be printed or simply reside in a data file or report file. Due to the proliferation of information systems, the variety and complexity of reports is almost unlimited. This is particularly true in distributed computing environments where data is often retrieved from separate databases in remote locations to process a report. However, as the size and sophistication of reports increase, ever increasing demands are placed on available processing resources, particularly when multiple reports are processed on the same machine that is executing the application software.
Consider the conventional report processing arrangement 100 illustrated in FIG. 1A which includes a client 102, a database server 104 and a database (DB) 106. When a report is to be prepared, a client application 108, executing on the client 102, starts a report process 110, which also executes on the client 102. The report process 110 then requests report data from a database management system (DBMS) 112, which in turn retrieves data from the DB 106. The report process 110 automatically terminates upon completion of the report. Each time a report is to be generated, the client application 108 initiates a new report process 110. If several reports are to be generated simultaneously, the client application 108 starts a new report process 110 for each report, which all execute simultaneously on the client 102.
There are several disadvantages with this arrangement 100. First, starting a new report process 110 for each report increases the report processing time because of the time required to start a new report process 110. Moreover, executing report processes 110 on the client 102 can strain the processing resources of the client 102, particularly when several report processes 110 are executed simultaneously.
To reduce the processing burden placed on the client 102, some report processing systems have transferred the report processing from the client 102 processor to a different processor. For example, in the report processing arrangement illustrated in FIG. 1B, the report process 110 has been transferred from the client 102 to the database server 104. When a report is to be processed, the client application 108 issues a report command to the DBMS 112 through a database pipe or other similar communications mechanism 114. A report handler 116 periodically polls the DBMS 112 to determine whether a report needs to be generated. When a report needs to be generated, the report handler 116 reads the report command from the DBMS 112 and then starts a report process 110 to process the report. A report definition file (RDF) 118 is opened for each report process 110.
This arrangement 100 minimizes the processing burden on the client 102 attributable to report processing, but the time required to process a report is still adversely affected by the overhead associated with starting a report process 110 each time a report is to be generated. In addition, the client application 108 does not have direct access to report status. The client application 108 is limited to issuing database commands to the DBMS 112 to determine report process 110 status. However, the DBMS 112 is not designed to be used as a status/message center to provide report status to the client application 108. Some DBMSs 112 do not provide any report status to a client application 108 after a report command has been sent to the DBMS 112.
In view of the difficulties associated with processing reports, and the limitations in the solution described above, a more effective method and apparatus for processing reports is highly desirable.